Run & review this pull request in StackBlitz Codeflow.

Error

agent completed without reporting progress

  ^{｜ Rerun failed job ➔ ｜ View workflow run ｜ Triggered by Pullfrog ｜ pullfrog.com ｜ 𝕏}

@malcolm-kee is attempting to deploy a commit to the Hey API Team on Vercel.

A member of the Team first needs to authorize it.

🦋 Changeset detected

Latest commit: 7594425

The changes in this PR will be included in the next version bump.

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

Codecov Report

❌ Patch coverage is 19.36128% with 404 lines in your changes missing coverage. Please review.
✅ Project coverage is 38.40%. Comparing base (51d56b3) to head (7f335ff).
⚠️ Report is 1 commits behind head on main.

@@            Coverage Diff             @@
##             main    #3570      +/-   ##
==========================================
- Coverage   38.99%   38.40%   -0.59%     
==========================================
  Files         515      540      +25     
  Lines       18901    20005    +1104     
  Branches     5591     6014     +423     
==========================================
+ Hits         7370     7683     +313     
- Misses       9326     9954     +628     
- Partials     2205     2368     +163     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@malcolm-kee Before I go into it, two questions:

1. How much AI was used to create this pull request?
2. How much are you willing to improve it? i.e. Is this the final version?

@mrlubos I come up with the API design and AI was doing most of the implementations while I watch.

Not final. I'm happy to iterate on this, just want some progress on this plugin.

The diff is big is mostly because of the tests and snapshots.

Open in StackBlitz

npm i https://pkg.pr.new/@hey-api/codegen-core@3570

npm i https://pkg.pr.new/@hey-api/json-schema-ref-parser@3570

npm i https://pkg.pr.new/@hey-api/nuxt@3570

npm i https://pkg.pr.new/@hey-api/openapi-ts@3570

npm i https://pkg.pr.new/@hey-api/shared@3570

npm i https://pkg.pr.new/@hey-api/spec-types@3570

npm i https://pkg.pr.new/@hey-api/types@3570

npm i https://pkg.pr.new/@hey-api/vite-plugin@3570

commit: cfefe18

I did some refactoring/enhancements:

• remove duplications of type definition and function param definition. It's only defined at type level and the implementation param is auto-inferred from that.
• extract example from schema as default value.

@mrlubos I manually validated the code and made some refactoring. It would be great if you can provide some feedbacks, especially on the API.

More revision:

• Redesign the API - the static parameter becomes { status: number; result: ResultType } instead of just ResultType. This design allows typescript to infer the types better with a stable object type with explicit properties instead of a more generic ResultType. This also make it easier to overwrite the status code without falling back to use the custom resolver approach.
• Forward the handler options to msw, so no lost of capabilities.
• Added resolveToNull helper function to remove duplicate fallbacks

Added examples options to the plugin.

Change plugin options from examples: boolean to valueSources: Array<'example'>, so that when fakerjs is ready, we just need to switch the default value to valueSources: ['example', 'faker'].

Ideas on how to continue enhancing this PR, in case anyone want to take over this, since I might not be free to iterate on this:

Implement ofAll

We can actually implement ofAll helper without waiting for faker plugin, by providing options to customize its behavior:

const createMock = createMswHandlerFactory();

const allMockHandlers = createMock.ofAll({
  onMissingMock: 'skip', // 'skip' | 'error',
  overrides: {
    getPetById({
      status: 200,
      result: { id: 1, name: "Fido", photoUrls: [] },
    })
  }
});

const server = setupServer(...allMockHandlers);

onMissingMock option:

• skip: we will not include the MSW handlers that requires argument in the returned array of requestHandlers. This is possible because we can infer if argument is required for a handler (I differentiate them by providing them different types - HttpHandlerFactory are those require argument while OptionalHttpHandlerFactory are those does not require argument)
• error: we will include the MSW handlers for all, but for those require argument, we will return HttpResponse('[heyapi-msw] The mock of this request is not implemented.', { status: 501 })

overrides option API is similar to the API of single handler, but instead of calling individual helper, user can define all of them at once here.

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
hey-api-docs	Ready	Preview, Comment	Mar 25, 2026 11:23pm

@malcolm-kee this is a really strong start! I found some errors with the OpenCode spec so I'm going to clean it up either way, here are the changes I've made so far:

1. Fallback base URL to *. It's easier to get something going that way, otherwise I was stuck on the very first step and had to figure out why it's not matching mocks.
2. Removed the _default mocks. It's easy to import and call createMswHandlerFactory() now to get the same result. I was bitten way too many times by the default HTTP clients we generate, not going to repeat the same mistake.
3. Added baseUrl allowing people to define their own default value or pick one from OpenAPI servers.
4. Smaller cleanup to the DSL usage.

I'll continue working on this, the main thing right now is the readability and organization of the generated code

@mrlubos I'm thinking of adding SSE support if #3657 looks good. But probably after this PR is merged.

@malcolm-kee New changes:

1. Removed the onMissingMock feature. Let me know if this is essential to you, I wanted to reduce the complexity for now. The default MSW warning works imo, but we might want to bring this back later since MSW Source also has something similar.
2. Moved single handler factories behind .one property to guarantee uniqueness. If we want to support more customization later, the original mocks spread could clash with getAllMocks. Speaking of...
3. Renamed .getAllMocks() to .all().
4. Major clean up of the output. The new structure exports every handler factory in addition to the umbrella wrapper. This unlocks a lot of goodies such as conditionally disabling the wrapper generation (if desired) or the ability to move individual exports to different files.

The last part is improving the actual handlers and fixing some bugs I found.

Removed the onMissingMock feature.

I'm concerned that it introduces invalid mock. In my experience, invalid mocks are a nightmare to debug because the resulting errors usually pop up in the UI logic, far away from the network layer.

We should probably force overrides to be required or ensure those handlers are skipped. The former approach makes the all helpers harder to use, while the latter is misleading as it's not all handlers - neither is good DX IMO.

Moved single handler factories behind .one property

I think it could be confusing, given that MSW handler has once option. What about .mock?

Major clean up of the output

Could we add explicit return type for createMswHandlers? Else the output will break projects with isolatedDeclarations mode.

Other than that, LGTM!

@malcolm-kee added explicit types back.

RE .one, this is the current result from the factory. It's closer to an ORM interface so I'd be surprised if people confuse it with .once – what would the assumption be? I can also add JSDoc comments to this interface later, I'm just being lazy right now.

RE onMissingMock, can you explain your concern? I assume you're saying that the mock could return data that doesn't match the expected shape which would explode your UI. That's a valid concern, but with your implementation I was using all mocks and MSW was not detecting them which felt weird too. It wasn't intuitive that I need to manually provide a response. Perhaps a middle ground would be to avoid handling operations if we can't guarantee the result is accurate. That way we're not forced to manually provide every response and .all() could be improved with a comment explaining how it works.

I want to make sure I understand your concern correctly — could you clarify a bit?

It wasn't intuitive that I need to manually provide a response

Were you using onMissingMock: 'skip' or 'error'? If the issue is that .all() silently skips mocking some requests, 'error' would surface which endpoints aren't being mocked. On the other hand, 'skip' allows relying on MSW's default unhandled request behavior to catch those.

I agree it feels odd that .all() doesn't actually mock all endpoints. The end goal is to provide sensible defaults for every endpoint (via the faker plugin when it's ready), so for now, skipping is the safer default to avoid returning invalid data.

If it's too confusing, we can ship this plugin without all() for now and add it once faker plugin is ready.

One more thing, not sure if it's intentional. I realize that in the latest implementation, all the first parameter becomes optional. It was made required previously as a signal to user that they must provide the mock response.

@malcolm-kee good eye – that one is intentional. If we're skipping or throwing an error on missing mocks, there's no need to provide any arguments. More importantly, this is the base experience I want people to have:

const server = setupServer(
  ...createMswHandlers().all(),
);
server.listen();

or with single handler:

const server = setupServer(
  createMswHandlers().one.tuiPublish(),
);
server.listen();

As with the rest of the ecosystem, it should just work™. In the end, the behavior I'm steering towards with this v0 is mock what we can (based on the examples field), and skip everything else. The above examples feel good to me, just need to bring back the onMissingMock behavior from your last comment.

After playing with it more, I agree that fake data is very high on the priority list. A lot of specs simply don't have example fields, which would make the default experience basically do nothing haha. Did you have an interest in working on that feature?

I agree with the principle of it should just work, but I want to push back a little, as I disagree that making the parameter optional is achieving that.

There are two scenarios when someone add a msw handlers:

• scenario 1: a flow that fetch some data from backend and use it for subsequent processing, e.g. display in UI
• scenario 2: a flow that make some API calls to backend, then doesn't care about its response as long it is returning successful status code

By making the parameter optional in all cases, we're making the life for scenario 2 easier but at the cost of scenario 1. Now that instead of letting the type guide them on which mock handlers can be used safely, they have to wait until the runtime error in the test to let them know if a manual mock data is required.

A middle ground that we can attempt is to apply different logic based on the method - get method should force the parameter as required when fallback is not available, and other methods can be always optional. I didn't do that because I tried to avoid making the logic even more complicated.

Last thing I want to point out is that this is a decision we had to make even with the faker plugin, because user might disable default value from faker with valueSources: [].

Yeah I'm interested in working on the faker plugin, didn't do anything yet cause I assumed you've started something?